The speed at which many fundamental business operations are being performed continues to increase, in some cases by several orders of magnitude. Increased operational velocity may be found in many, varied business areas. These include, for example, stock trading analytics, airline operations, call center inquiries, financial position tracking, supply chain updating, document transfer, phone activation, data warehouse refreshing, trade settlement, build-to-order personal computers, and many others. Most of the increases in speed of operations are integrally tied to the use of information technology. However, increases in business operation velocity have occurred while at the same time a plateau is being reached with regard to the speed at which information technology software can adapt to changes. Since software is the core underlying information technology capabilities, and since the importance of information technology to most businesses is increasing, this is a significant concern.
In many aspects, the practice of software development remains relatively “low-tech”. Production of software applications at the development stage is non-scalable. Software quality is generally decreasing. As a result, the speed at which information technology can respond to a need for new or improved functionality is often much slower than the speed at which the business itself is operating.
It is increasingly apparent that the old model of simply adding new software applications to meet each new business need no longer holds. Enterprises believe they have more than enough software applications. Some of this software infrastructure is considered an asset, while other parts are seen as liabilities. Thus software integration has become at least as important as new software development. However, the practice of software integration is substantially less developed than that of software development. The results of software integration are accordingly often less sustainable than those of software development, and the two disciplines for the most part remain orthogonal practices.
Some attempts at improving software integration have been made addressing the distribution and use of software components. The emerging standards and technologies generally referred to as “Web Services” exemplify such efforts. Web Services standards provide an approach for documenting software interfaces using a specific XML structure (WSDL). Web Services infrastructure technologies provide a distribution system for these documented interfaces (SOAP/XML, UDDI). By helping facilitate standard access to exposed components, Web Services may accelerate component re-use by new or different applications. However, Web Services technologies fail to address key issues in the software production process that are likely to cause extensive re-use of software components to increasingly compromise the quality and durability of both the original applications providing the re-used components, and of the new applications that consume them.
Specifically, “wrapping” existing applications as Web Services does not change their fundamental architecture. Accordingly, such an approach will not make the application systems underlying the exposed components any more reusable, nor will it make them any more capable of managing interactions with new applications that are going to consume their services. The increasing re-use of existing components resulting from such partial solutions, primarily via new use cases, typically falls outside the boundary conditions for which the applications containing them were designed and optimized. Such “unintended” re-use increasingly compromises performance and quality of service in applications comprising the re-used components. Moreover, the more diversified and extensive the re-use, the larger the cost and effort of maintaining the desired level of service in the applications comprising the re-used components. Similarly, diverse and extensive component re-use increases the range of risks caused by the accumulated impact of new component interactions on systems that consume the services provided by the re-used components. This results significantly from the fact that the consuming application as no effective control over the operation of the re-used components within the original applications. Moreover, while new software-based system initiatives should have minimal impact on existing operations, they should also foresee the need for eventual integration of their own components into subsequently developed, as of yet undefined applications.
Thus the problems raised by increasing software component reuse have been insufficiently addressed by previous approaches. This is true both from the point of view of (a) existing applications including the components whose services are to consumed, and (b) new or “composite” applications being developed that consume the services of such reused components. To the extent that insufficient approaches encourage component reuse without providing a full solution to the problems raised thereby, they exacerbate significant problems they do not address.
There is accordingly a need for a new approach to designing, developing and maintaining cohesive, high-performance composite applications. Applications may be considered “composite” applications when they provide new or changed functionality involving interaction between software components that were not originally designed to work together, such as existing components provided by different software applications, new components consuming services from different software applications, or new components enhancing functionality or enabling new use cases in existing applications. Previous systems lack an appropriate application model for composite applications, and also lack a practical dynamic integration technique that limits the high costs associated with the combinatorial impact of changes.
While all applications would benefit from use of an application model, and from a technique for limiting the costs associated with the combinatorial impact of making dynamic changes, the needs are even greater in the area of composite applications, because of the increased likelihood of changes in the composite application environment. This is true not only for any given current generation of composite applications, but also for future generations of composite applications that may be anticipated. Accordingly, the need to provide reliable, sustainable changes is amplified in the area of composite applications because changes are more likely than in non-composite application environments.
With regard to the lack of an application model for composite applications, existing application models have either been rigid, as in the area of form processing, or limited in scope, as in page-based Web browsing. Contemporary software applications often lack any application model at all, and it is therefore impossible to ensure that they provide a sustainable business advantage as their functionality changes. In sum, existing application models fail to anticipate the basic needs of composite applications.
With regard to the combinatorial impact of changes, it should be reflected in contemporary methods for producing software applications. Clearly, object-oriented software development technologies have become the preferred tools for most software engineering. Accordingly, components within an application are generally implemented as objects, each associated with corresponding object-oriented “class”. In particular, the mechanism of Inheritance in object-oriented software is limited, in that Inheritance relationships are pre-defined at compile time or link time by their classes. All components in a given Inheritance graph have to be compiled together into a single binary module, and a change to any component for use in a composite application may require re-compiling, possibly re-linking, and re-deploying of a new binary module. Accordingly, even singular or relatively small changes can significantly impact software system deployment. In addition, since Inheritance is tightly-coupled to a given set of components, a change in any given component may impact all the heirs of that component's class, with the result that a large number of potential side-effects on other components may need to be carefully evaluated and tested.
Dynamic modifications to applications have been attempted in previous systems by changing class definitions of one or more application components. However, significant shortcomings have arisen relating to the fact that Inheritance is a class property, rather than an object property. Accordingly, systems for modifying software applications have been further limited by the bounding of the late-binding of component objects to the Inheritance graphs of their classes, for example as defined at compile time. As shown in FIG. 1, an Inheritance relationship 10 between Class1 and Class2 for an application component is present at Application Design-Time 12, when the Object Definitions 16a are provided, while at Application Run Time 18 the Compiled Component 14 following compilation 15 instantiates Application Runtime Objects 16 resulting in Application Objects O1a and O2a. As shown in FIG. 2, a desired change 20 in an application as it exists at a time T1, and detected at Application Run-Time 18, may need to be made through a application design time change 22 at time T2, and result in re-compiling 24, followed by re-deployment of the new version of the Compiled Component 26, and possibly updating the Application Runtime Objects 16 through the new Object Definitions 17a resulting in Application Runtime Objects O1b and O2b in the new Application Runtime Objects 17b. 
FIGS. 3 and 4 illustrate the deleterious effects of the fact that Inheritance in existing systems is tightly-coupled to a development time class hierarchy. This is especially relevant to previous “leave and layer” approaches to software component re-use, which may requisite changes to facilitate component reuse that ripple through the entire development time class hierarchy. As shown in FIG. 3, a change to Class C19 31 in the Class hierarchy 32 is made at Application Development Time 30 in order to change the associated Component 36 in the Application 38 after compilation 34. As a result, at Application Run-Time 39, within the Application Data 42 used at Application Run-Time 39, there are associated changed Data Objects 40. In FIG. 4, at Application Development Time 64, a change to the Class C2 50 results in changes to its heir Classes 52. After compilation 58, the Application 56 includes modified Components 54, which result in the modified Data Objects 60 with respect to the Application Data 62 at Run-Time 66. Thus the principle of Inheritance can thus explode the total number of changes needed to provide a significant change at a high level within a class hierarchy of an application that includes components to be re-used within a composite program, and/or of a composite application itself.
In conclusion, a new system and method are needed for providing composite applications should include an application model that facilitates integration of re-used application components into composite applications, and anticipate the integration and re-use of the composite applications themselves into subsequent composite applications. Since such a model would motivate increased application integration and component re-use, the new system should also constrain costs associated with the combinatorial effects associated with changes needed to handle new and evolving use cases. Overall, the system should provide information technology systems with the capacity to adapt to changes at a rate comparable to the increasing operational speeds and change rates in the businesses they support.